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ABSTRACT 


The  Canadian  Navy  has  been  developing  a  highly  fault-tolerant,  integrated  navigation  sys¬ 
tem  for  its  dual-INS  equipped  frigates  for  a  number  of  years.  The  system,  called  DUNS 
(Ehial  Inertial  Integrated  Navigation  System),  is  now  in  the  final  stages  of  sea  trials  before 
being  prepared  for  installation  on  the  vessels.  This  report  provides  a  high  level  overview  of 
the  system. 


RESUME 

La  marine  canadienne  a  developpe  un  systeme  de  navigation  integre  fortement  insensible 
aux  defaillances  pour  ses  fregates  6quipees  par  double-INS  dqpuis  un  certain  nombre 
d'annees.  Le  syst&ne,  appele  DENS  (systeme  double  de  navigation  integre  in^iel),  est 
maintftTiant  aux  6tapes  finales  des  epreuves  en  mer  avant  d'etre  prepare  pour  I'installation  sur 
les  navires.  Ce  rapport  foumit  une  vue  d'ensemble  de  niveau  eleve  du  systeme. 
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EXECUTIVE  SUMMARY 


The  Defence  Research  Establishment  Ottawa  has  been  developing  a  highly  fault-tolerant, 
integrated  navigation  system  for  the  Canadian  Navy’s  dual-INS  equipped  ships  for  a  number 
of  years.  The  system,  called  DIINS  (Dual  Inertial  Integrated  Navigation  System),  has 
undergone  extensive  sea  trials  and  is  now  being  prepared  for  fitting  on  the  vessels.  Exter¬ 
nally,  DIINS  provides  best  estimates  of  ownship  navigation  data  for  an  ECDIS  Electronic 
Chart  and  Display  Information  System)  on  the  bridge,  and  for  the  ship's  command  and 
control  system.  Internally  DENS  implements  multiple,  cooperating  Kalman  filters  to  enable 
the  application  of  sensitive  Failure  Detection,  Isolation  and  Reconfiguration  (FDIR)  tech¬ 
niques  and  to  provide  high  system  reliability  and  navigation  accuracy.  The  sensors  being 
integrated  include  two  inertial  navigation  systems  (INS's),  GPS  (PPS,  SPS  and/or  differen¬ 
tial),  speed  log,  and  Loran-C.  The  application  of  multiple  parallel  filters  and  precise 
statistical  error  tests  to  redundant  inertial  navigation  systems  has  been  very  limited  until  the 
most  recent  generations  of  microprocessors.  Such  a  system  is  significant  in  that  the  design 
has  been  optimized  for  automatic  failure  detection  and  reconfiguration  and  to  provide 
navigation  information  in  decreasing  but  known  accuracy  as  sensors  fail;  thus  the  operator 
can  always  be  confident  that  the  best  remaining  sensors  are  being  used  to  navigate.  Such  a 
complex  and  comprehensive  integrated  navigation  system  is  quite  unique  among  the  world's 
navies  and  this  program  is  generating  interest  among  allied  nations.  This  report  begins  with 
an  overall  review  of  the  intent  of  the  DENS  program,  and  outlines  the  physical  architecture 
and  operator  interaction  with  the  system.  It  then  goes  into  detdls  of  the  Kalman  filter 
integration  and  failure  detection  methods  that  have  been  chosen,  reviews  some  sea  trial 
results  that  have  been  obtmned  and  briefly  discusses  the  implementation  of  DENS  within  the 
fleet.  Finally,  two  appendices  detail  the  DENS  output  data  that  is  generated  for  distribution 
for  any  user  systems  on  the  ship. 
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SOMMAIRE 


Le  Centre  de  recherches  pour  la  defense  Ottawa  d^veloppe,  depuis  un  certain  nombre 
d'annees,  un  systeme  integre  de  navigation  a  forte  tolerance  des  defaillances  pour  les  navires 
de  la  marine  canadienne  equipts  d'un  systdme  INS  double.  Le  systeme,  appele  DIINS 
(systeme  integre  double  de  navigation  par  inertie),  a  subi  des  essais  en  mer  pousses,  et  on 
I'adapte  actuellement  en  vue  d'une  exploitation  a  bord  des  navires.  Du  point  de  vue 
fonctionnel,  le  DIINS  foumit  les  meilleures  evaluations  des  donn^es  de  navigation  du  navire 
pour  le  SEVCM  (systeme  electronique  de  visualisation  des  cartes  marines)  sur  le  pont  et 
pour  le  systeme  de  commandement  et  de  controle  du  navire.  Du  point  de  vue  interne,  le 
DENS  comporte  de  multiples  filtres  de  Kalman  associes  permettant  I'application  de 
techniques  de  detection  de  defaillance,  d'isolement  et  de  reconfiguration  (TOIR)  a  sensibilite 
61evee  et  offrant  une  fiabilite  et  une  prteision  de  navigation  de  niveau  superieur.  Les 
d^tecteurs  int^gr^s  comprennent  deux  systemes  de  navigation  par  inertie  (INS),  un  GPS 
(PPS,  SPS  et/ou  GPS  differentiel),  un  loch  et  un  Loran-C.  Avant  que  les  plus  recentes 
generations  de  microprocesseurs  aient  fait  leur  apparition,  les  filtres  paralieies  multiples  et 
les  essais  precis  d'erreurs  statistiques  etaient  tr^s  peu  utilises  dans  les  systemes  redondants 
de  navigation  par  inertie.  Le  nouveau  systeme  marque  un  progres  important,  car  sa 
conception  a  ete  optimisee  pour  executer  automatiquement  la  detection  des  defaillances  et  la 
reconfiguration  ainsi  que  pour  fbumir  de  I'information  de  navigation  de  precision 
decroissante  mais  connue  a  mesure  que  les  detecteurs  tombent  en  panne.  L'operateur  est 
done  toujours  assure  que  les  meilleurs  detecteurs  restants  sont  utilises  pour  la  navigation. 

Ce  systeme  integre  de  navigation,  complexe  et  global,  est  le  seul  de  son  genre  dans  les 
marines  du  monde,  et  ce  programme  suscite  de  I'interet  chez  nos  allies.  Le  rapport 
commence  par  une  vue  d'ensemble  des  objectifs  du  programme  DENS,  puis  decrit 
Tarchitecture  materielle  et  I'interaction  de  l'operateur  avec  le  systeme.  II  donne  ensuite  des 
details  sur  les  m^thodes  choisies  d'int^gration  des  filtres  de  Kalman  et  de  detection  des 
defaillances,  examine  certains  resultats  d'essais  en  mer  et  traite  bri^vement  de  la  mise  en 
service  du  DENS  a  I'interieur  de  la  flotte.  Enfin,  deux  annexes  donnent  des  details  sur  les 
donnees  de  sortie  du  DENS,  distribuees  a  tous  les  systemes  utilisateurs  du  navire. 
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1.  INTRODUCTION 


1.1.  Background 

The  Defence  Research  Establishment  Ottawa  has  been  developing  a  highly  fault-tolerant, 
integrated  navigation  system  for  the  Canadian  Navy’s  dual-INS  equipped  ships  for  a  number 
of  years.  The  system,  called  DUNS  (Dual  Inertial  Integrated  Navigation  System),  has 
undergone  extensive  sea  trials  and  is  now  being  prepared  for  fitting  on  the  vessels.  Exter¬ 
nally,  DUNS  provides  best  estimates  of  ownship  navigation  data  for  an  ECDIS  (Electronic 
Chart  and  Display  Information  System)  on  the  bridge,  and  for  the  ship's  command  and 
control  system.  Internally  DUNS  implements  multiple,  cooperating  Kalman  filters  to  enable 
the  application  of  sensitive  Failure  Detection,  Isolation  and  Reconfiguration  (FDIR)  tech¬ 
niques  and  to  provide  high  system  reliability  and  navigation  accuracy.  The  sensors  being 
integrated  include  two  inertial  navigation  systems  (INS's),  GPS  (PPS,  SPS  and/or  differen¬ 
tial),  speed  log,  and  Loran-C.  The  application  of  multiple  parallel  filters  and  precise 
statistical  error  tests  to  redundant  inertial  navigation  systems  has  been  very  limited  until  the 
most  recent  generations  of  microprocessors.  Such  a  system  is  significant  in  that  the  design 
has  been  optimized  for  automatic  failure  detection  and  reconfiguration  and  to  provide 
navigation  information  in  decreasing  but  known  accuracy  as  sensors  fail;  thus  the  operator 
can  always  be  confident  that  the  best  remaining  sensors  are  being  used  to  navigate.  Such  a 
complex  and  comprehensive  integrated  navigation  system  is  quite  unique  among  the  world's 
navies  and  this  program  is  generating  interest  among  allied  nations.  This  report  begins  with 
an  overall  review  of  the  intent  of  the  DUNS  program,  and  outlines  the  physical  architecture 
and  operator  interaction  with  the  system.  It  then  goes  into  details  of  the  Kalman  filter 
integration  and  failure  detection  methods  that  have  been  chosen,  reviews  some  sea  trial 
results  that  have  been  obtained  and  briefly  discusses  the  implementation  of  DUNS  within  the 
fleet.  Finally,  two  appendices  detail  the  DUNS  output  data  that  is  generated  for  distribution 
for  any  user  systems  on  the  ship. 


1.2.  Overview 

DUNS  provides  integrated  navigation  data  to  an  electronic  chart  system  by  integrating  the 
data  from  the  twin  Sperry  MK-29  (or  49)  INS's  with  the  GPS,  DGPS,  speed  log  and  other 
nav-aids  onboard  Canada's  Halifax-class  patrol  frigates  (CPF).  This  provides  an  accurate 
and  reliable  optimal  position  estimate  that  is  highly  robust  with  respect  to  sensor  failures.  It 
does  this  through  a  scheme  of  multiple,  parallel  Kalman  filters  and  a  sophisticated  Failure 
Detection,  Isolation  and  Reconfiguration  (FDIR)  module.  DUNS  is  the  product  of  several 
years  of  research  and  development  effort,  and  is  currently  in  the  Advanced  Development 
Model  (ADM)  phase.  The  experimental  development  model  (XDM)  developed  at  DREO, 
has  been  tested  onboard  HMCS  Calgary,  and  provided  integrated  INS/GPS  data  to  drive  the 
chart's  displays,  if  selected  to  do  so  by  the  operator.  References  [1],  [2],  and  [3]  describe 
DUNS  in  earlier  forms.  Ref  [4]  describes  its  predecessor  MINS  (Marine  Integrated  Naviga¬ 
tion  System).  References  [5],  [6],  [7]  and  [8]  describe  the  theoretical  and  algorithmic  details 
of  the  DUNS  internal  filtering. 
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DIINS  has  been  designed  to  be  housed  within  a  bridge-resident  electronic  charting  system 
called  SHINNADS  (Figure  1).  SHINNADS  (Shipboard  Integrated  Navigation  And  Display 
System)  is  a  full  Electronic  Chart  and  Display  Information  System  (ECDIS)  that  is  being 
procured  from  Offshore  Systems  Ltd.  of  North  Vancouver  B.C.  by  the  Canadian  Navy  for  its 
main  surface  fleet.  SHINNADS  has  been  designed  by  the  Navy  to  interface  to  the  CPF’s 
INS,  speed  log,  navigation  radar  and  P/Y  GPS  receiver,  and  provides  a  number  of  features 
of  interest  to  the  Navy  in  its  software.  In  addition,  an  interface  to  DIINS  allows 
SHINNADS  to  accept  and  display  die  integrated  navigation  solution  from  the  DUNS 
processor,  which  is  to  be  housed  in  the  VME  card  cage  in  the  SHINNADS  console. 
SHINNADS  has  both  a  VME  computer  that  hosts  the  charting  functions,  and  an  OS/2  PC 
that  hosts  a  number  of  configuration  and  file  server  utilities. 


Figure  1:  The  DIINS/SHINNADS  Console 
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2.  MOTIVATION  FOR  DIINS 


Without  DIINS,  the  SHINNADS  system  typically  obtains  its  navigational  information  from 
a  commercial  differential  GPS  receiver  that  is  housed  v^ithin  its  own  console.  In  a  naval 
environment  however,  DGPS  is  generally  not  considered  to  be  sufficient  in  many  cases. 
While  the  accuracy  and  availability  of  DGPS  is  unmatched  in  friendly  coastal  areas,  navy 
ships  must  be  equipped  to  operate  in  all  comers  of  the  world.  Commercial  GPS  and  DGPS 
receivers  are  vulnerable  to  jamming  and  spoofing  by  hostile  forces  or  by  unintentional 
means.  High  value  naval  assets  must  have  reliable  and  self  contained  navigation  equipment 
to  sustain  their  combat  operations  during  times  of  GPS  unavailability.  In  addition,  weapons 
and  sensors  require  high  rate  attitude  information  not  available  from  GPS.  Thus  almost  all 
modem  naval  warships  have  dual  Inertial  Navigation  Systems  (INS’s)  that  are  capable  of 
operating  autonomously  for  long  periods  of  time  without  external  updates.  Submarines  are 
an  especially  important  case. 

The  twdn  INS’s  offer  redundancy  of  navigational  information  in  case  of  catastrophic  loss  of 
one  of  the  units.  The  INS’s  also  provide  heading  and  attitude  data  that  is  used  throughout 
the  ship  in  the  critical  sensor  and  weapons  systems  that  enable  the  ship  to  conduct  its 
operations.  Therefore  the  inertial  navigators  are  considered  the  heart  of  the  ship’s  naviga¬ 
tion  system  and  the  presence  of  two  such  units  on  each  ship  provides  for  an  excellent 
opportunity  for  a  highly  integrated  and  robust  navigation  system.  Such  a  system  can  config¬ 
ure  itself  to  use  the  best  combinations  of  sensors  available  and  to  continuously  monitor  the 
status  of  all  the  individual  sensors  to  remove  any  failed  or  failing  sensors  from  the  naviga¬ 
tion  solution.  Up  until  this  point,  the  various  navigation  sensors  were  often  very  loosely 
integrated  (or  not  at  all)  and  full  exploitation  of  the  rich,  redundant  information  has  not  been 
obtained.  The  ability  to  detect,  isolate  and  remove  failed  sensors  from  the  navigation 
solution  was  a  primary  motivation  for  the  development  of  the  DIINS  system. 


3.  Dims  EXTERNAL  ARCHITECTURE 

The  external  architecture  of  the  DIINS/SHINNADS  system  as  implemented  on  Halifax  class 
ships  is  shown  in  Figure  2.  The  DUNS  navigation  computer  optimally  combines  data  from 
all  the  sensors  into  a  single  best  estimate,  while  performing  sensor  error  detection.  It 
provides  this  estimate  to  the  SHINNADS  ECDIS  display  and  can  distribute  the  data  to  other 
users.  SHINNADS  also  overlays  the  radar  data  provided  by  the  navigation  radar  as  well  as 
plotting  tracked  contacts  from  the  radar's  ARP  A  (automated  radar  plotting  aid)  function  if 
available.  In  SHINNADS  systems  that  do  not  have  the  DUNS  subsystem,  ownship  naviga¬ 
tion  data  is  provided  by  an  internal  DGPS  set,  complimented  by  synchro  heading  and  speed 
available  from  the  ship's  synchro  distribution  system.  (It  also  has  a  number  of  other  inter¬ 
faces  for  ancillary  equipment  such  as  anemometers  and  depth  sensors.)  The  primary  sensors 
that  DUNS  integrates  are  the  two  inertial  systems  and  the  P/Y  code  GPS  receiver.  DGPS  is 
also  used  when  available.  Loran-C  is  also  a  viable  input  and  is  also  used  when  available. 
DENS  does  have  the  capability  to  use  ship’s  speed  log,  but  in  the  current  implementation  on 
the  Halifax  class  ships,  it  does  not  use  it  directly.  Rather  the  inertial  systems  are  “speed  log 
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damped”  meaning  the  log  is  used  as  an  input  to  the  INS’s  which  use  it  to  damp  their  internal 
velocity  errors,  which  would  otherwise  undergo  Schuler  oscillations  [13]. 


Pos/'Amude 


Pos/Speed/Hdg 


Figure  2:  DENS  External  Architecture 


Physically  DENS  consists  of  3  VME  computer  cards  that  reside  in  a  bridge-resident  standup 
console  along  with  SHBSINADS  (Figure  1).  The  primary  display  is  a  21”  monitor  with 
keyboard  and  trackball  input.  Sensor  inputs  are  typically  RS-232/422  or  synchro.  DENS 
computes  and  sends  its  optimal  navigation  output  to  SHINNADS  VME  computer  via  an  RS- 
232  output  and  accepts  configuration  commands  from  the  SHINNADS  PC  computer  on 
another  serial  port.  DENS  incorporates  an  optional  serial  output  of  high  rate  navigation  and 
attitude  data  for  distribution  to  other  potential  users  on  the  ship.  A  complete  description  of 
this  output  stream  is  included  in  Appendix  A. 
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4.  OPERATOR  INTERFACES 

There  are  two  basic  operator  interfaces  through  which  a  user  interacts  with  DIINS.  One  is 
the  Navigation  Display  screens  that  are  displayed  on  the  SHINNADS  console.  The  second 
is  the  DIINS  HCI  (human  computer  interface)  program  that  resides  on  a  PC  inside  the 
SHINNADS  console.  On  the  console  is  a  simple  rocker  switch  that  allows  either  the  VME 
based  Navigation  screens  or  the  PC  based  configuration  and  setup  screens  to  be  shown  on 
the  display. 

4.1.  DIINS  Navigation  Dispiay  Screens 

When  DIINS  is  operating  in  normal  fashion  within  SHINNADS,  and  the  operator  has 
selected  DUNS  as  the  position  source  it  is  to  use,  any  of  the  dozen  or  so  SHINNADS  screen 
layouts  can  be  used  and  the  underlying  position  source  will  be  identified  on  the  screen  as 
DIINS.  In  addition,  two  special  screens  have  been  designed  for  use  with  DIINS  that  convey 
more  information  to  the  operator.  These  screens  are  shown  in  Figure  3  and  Figure  4.  Figure 
3  shows  the  DIINS  DETAILED  screen.  The  position  of  the  chart  is  driven  by  DIINS  and 
the  numerical  data  is  displayed  in  text  boxes  around  the  graphical  chart.  (Appendix  B 
details  from  where  in  the  DIINS  data  stream  each  field  on  the  display  obtains  its  data.) 


Figure  3:  DIINS  Detailed  Navigation  Display 
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Starting  in  the  upper  left  comer  of  Figure  3,  the  first  text  box  contains  a  large  font  with  the 
primary  data  required  to  steer  the  ship:  present  speed  made  good  (SMG)  and  course  made 
good  (CMG)  over  ground,  present  heading  (GYRO),  water  speed  (LOG)  and  rate  of  turn 
(ROT).  All  of  these  except  the  Log  are  from  DIE^S.  Water  speed  comes  directly  from  the 
ship's  speed  log  via  a  syncho  interface  in  SEQNNADS. 

The  next  box  displays  the  current  position  source  (DIINS)  and  some  information  about  the 
present  GPS  satellite  coverage  and  differential  correction  status  (These  will  probably  be 
removed  in  a  later  version  of  this  screen  as  they  are  not  really  relevant  at  this  level). 

Next  is  the  integrated  position  solution  from  DIINS.  This  is  the  best  available  estimate  of 
ownships  position  and  has  been  arrived  at  by  the  DIINS  internal  Kalman  filters  which 
optimally  weight  the  data  from  each  of  the  position  sources.  These  filters  are  described  in 
more  detail  in  the  next  section  and  are  fully  described  in  ref  [6].  Also  in  this  box  is  a  display 
of  the  estimated  accuracy  of  the  blended  solution.  This  is  presented  in  two  forms:  as  North 
and  East  standard  deviations,  and  as  a  95th  percentile  circular  error  probable  (CEP).  This 
95%  value  indicates  that  the  tme  position  of  the  ship  is,  to  a  probability  of  0.95,  within  a 
circle  of  the  displayed  radius  from  the  DIINS  estimated  position. 

The  next  box  displays  the  basic  DIINS  status  indicators.  The  overall  Status  can  be  one  of 
three  states: 

-  "Good"  -  there  is  at  least  one  good  INS  and  one  good  Kalman  filter  operating 

-  "Single  Sensor"  -  There  is  no  healthy  integrating  filter  (typically  because  both 
INS’s  have  failed)  and  the  best  available  single  sensor  is  being  used  for  output 

-  Failed  -  if  all  available  sensors  have  failed,  the  display  turns  red  and  data  is  not 
output  until  at  least  one  sensor  returns  to  good  health. 

Also  in  this  box  is  a  list  of  the  sensors  that  are  currently  being  integrated  to  determine  the 
blended  solution. 

Across  the  bottom  are  five  windows,  one  for  each  of  the  primary  navigation  sensors  -  the 
two  INS's,  two  GPS's  and  the  Loran  receiver.  In  each  box  is  the  raw  position  provided  by 
each  sensor,  as  well  as  the  heading,  speed,  course  and  status  information  from  that  sensor. 
These  can  be  used  by  the  operator  to  visually  confirm  the  reasonableness  of  each  sensor  and 
the  blended  solution.  Generally  the  DIINS  position  will  be  quite  close  to  the  GPS  positions. 
Note  however,  that  the  DIINS  position  is  by  default  the  center  of  the  ship,  and  the  GPS's 
report  the  positions  at  the  antennas  which  can  be  several  1 0's  of  meters  away  from  ship's 
center  (or  a  noticeable  fraction  of  an  arc  minute  of  latitude  or  longitude).  DIINS  correctly 
accounts  for  these  lever  arm  distances,  and  the  lever  arms  can  be  changed/verified  in  the 
DIINS  configuration  program  resident  on  the  PC. 

A  simpler  DIINS  display  is  available,  as  is  shown  in  Figure  4.  The  data  from  the  individual 
sensors  is  not  displayed,  leaving  more  room  for  the  chart.  The  rest  of  the  data  windows  are 
the  same  as  the  previous  layout. 
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Figure  4:  DIINS  Simplified  Navigation  Display 


4.2.  DIINS  HCI  Utility 

A  number  of  DIINS  configuration  parameters  can  by  viewed  or  changed  by  running  a  PC 
based  utility  program  developed  for  this  purpose.  The  program  resides  on  the  OS/2  PC 
within  the  SHINNADS  console  and  can  be  accessed  by  selecting  the  PC  on  the  rocker 
switch  on  the  console  and  running  the  program  (called  DIINS  HCI),  The  initial  screen  of 
the  DIIINS  HCI  that  is  presented  to  the  operator  is  shown  in  Figure  5.  This  program  enables 
the  operator  to: 

-  select  which  sensors  are  available4o  DIINS; 

-  install  specific  sensors  in  this  DIINS  configuration; 

-  enter  the  lever  arms  describing  the  position  of  each  sensor  relative  to  the  refer¬ 
ence  position; 

-  select  the  communications  settings  (baud  rate,  etc.)  for  each  sensor; 

-  change  some  of  the  sensor  measurement  failure  detection  thresholds; 

-  enable  data  logging  for  onshore  post-mission  analysis; 
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-  manually  disable/enable  sensors  while  DIINS  is  running  (part  of  SelectSensors)  . 

All  of  these  features  (except  for  the  last  one)  are  changeable  only  when  DHNS  first  starts  up. 
Only  the  manual  sensor  disable/enable  can  be  used  after  the  DIINS  Kalman  filters  are 
running.  To  change  any  of  the  other  parameters,  DIINS  must  be  restarted.  DIINS  can  be 
restarted  at  sea  without  restriction.  Valid  navigation  data  will  be  available  within  minutes  of 
the  restart,  provided  the  sensors  are  operating  normally.  The  Kalman  filters  quickly  con¬ 
verge  to  their  operating  values. 

There  are  a  number  of  Kalman  filter  parameters  that  cannot  be  changed  by  the  operator. 
These  parameters,  such  as  gyro  bias  random  walk  standard  deviations  and  correlation  times, 
should  only  be  changed  as  a  result  of  a  fine  tuning  process  by  a  knowledgeable  Kalman 
filter  designer.  These  parameters  are  stored  in  non-volatile  memory  in  the  DIINS  system 
and  can  be  changed  in  the  laboratory  (or  onboard  with  special  computer  interface  hardware). 


i  CoadDtoslktiaFojrChaiiglng  \ 


Time  Left  to  Load  Dilns  Data  for  Changing 


153  sec 


|/ PistributeHigtinatepata*! 


f :  /-  v"Syst«'inSta'tusi;,;;  /- ,, 


'  '-.OpefiSMonalMbd'e^ .  \  '-J  ,  SayeCofingPata | 


Sentence  from  pSns  Fteceiveif  .  ,  _  _ _ _ '  ~  ^  ^ . . .  . f .  * ,  - _ 


Figure  5:  DENS  HCI  Setup  and  Configuration  Display 


A  separate  manual  regarding  the  use  of  the  DIINS  HCI  can  be  found  in  Reference  [11] 
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5,  DENS  INTERNAL  ARCHITECTURE 

The  DIINS  core  software  has  been  designed  to  be  as  flexible  as  possible.  All  of  the  software 
has  been  written  in  ADA  and  is  highly  configurable.  Since  the  core  DIINS  Kalman  filtering 
software  is  quite  generic,  it  has  the  ability  to  use  many  more  sensors  than  are  available  on 
the  ships  (GPS  attitude  being  a  prime  example).  The  internal  architecture  of  DIINS  is  not 
one  Kalman  filter,  but  is  actually  a  family  of  concurrent,  cooperative  filters  arranged  in  a 
hierarchy  with  different  subsets  of  sensors  integrated  by  each  filter.  Reference  [5]  describes 
the  internal  filtering  in  full  detail.  This  section  summarizes  the  main  features  of  the  internal 
Kalman  filters  and  the  design  of  the  failure  detection  algorithms  in  DIINS.  A  good  Kalman 
filter  reference  can  found  in  [12]. 


5.1.  Individual  Kalman  Filters 


The  filters  are  error  state,  extended  Kalman  filters,  each  tjrpically  estimating  the  errors  in 
one  of  the  two  inertial  systems  by  using  the  data  available  from  one  or  more  of  the  aiding 
sensors  (GPS,  speed  log,  etc.). 

Each  filter  has  a  state  vector  of  the  form: 

—  —  —  ^  'f 

X  =  ^ 

The  state  vector  for  each  filter  differs  slightly  as  they  each  integrate  different  subsets  of  the 
sensor  suite.  The  DIINS  Kalman  filters  can  model  either  gimballed  or  strapdown  platform 
INS’s  and  use  a  psi-angle  error  formulation.  The  INS  states  are  error  states  consisting  of 
position  error  (r  ),  velocity  error  (v  ),  and  attitude  error  {ip ),  as  well  as  3  gyro  bias  (sq) 
and  2  (or  3)  accelerometer  bias  (^^  )  Markov  states  (depending  on  the  INS  mechanization): 

xiNS  =  [r  ^  9  h  hf 

The  aiding  sensor  states  for  the  GPS,  DGPS  and  Loran  receivers  are  modelled  as  exponen¬ 
tially  correlated  Markov  processes,  with  the  GPS  having  2  position  error  and  one  time  lag 
Markov  states: 


^GPS  ~  \j‘x  '^gps\  > 

and  Loran  having  4  time  difference  error  Markov  states  (converted  to  equivalent  range 
difference  errors.  A? ),  one  for  each  pair  of  stations  in  the  chain: 

^  ^  ^  ^  ^  T 

XWRAN  -i^TDw  ^TDx  ^TDy  ^TDz^  • 
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The  measurements  for  the  filters  consist  of  misclosures.  These  are  defined  as  the  differences 
between  the  aiding  sensor  and  the  INS  sensor  used  in  that  filter.  For  example,  a  position 
measurement  from  an  aiding  sensor  minus  the  current  INS  position  is  the  measurement  that 
is  used  in  the  Kalman  filter: 


Zy  =  yAid  -  yiNS 

Velocity  measurements  are  handled  similarly.  Care  is  taken  to  ensure  that  all  measurements 
are  converted  to  consistent  coordinate  frames  and  that  all  lever  arms  are  properly  accounted 
for  before  they  are  used  in  the  simple  difference  equations  of  this  type.  This  is  done  so  that 
the  matrix  representing  the  relationship  between  the  measurements  and  the  states  (the  “/f  ’ 
matrix)  is  relatively  simple  (generally  linear  time  invariant).  This  significantly  simplifies 
the  propagation  of  the  filter  covariance  matrix.  The  tradeoff  is  the  extra  pre-processing  re¬ 
quired  on  the  measurements  before  they  are  differenced.  All  DENS  Kalman  filters  are 
numerically  stable  UDU^  formulations. 


5,2.  Failure  Detection,  Isolation,  And  Reconfiguration  (FDER) 

The  FDIR  algorithm  in  DENS  is  the  key  to  system  reliability.  Reference  [6]  describes  this 
in  full  detail.  The  basic  design  philosophy  is  to  have  multiple,  simultaneous,  independent 
Kalman  filters  to  ensure  that  for  every  possible  failure,  there  is  at  least  one  filter  which  is 
uncorrupted  by  the  failure.  The  internal  architecture  of  DENS  filtering  scheme  is  shown  m 

Figure  6. 
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Figure  6:  DENS  Internal  Architecture 
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The  filters  shown  in  Figure  6  require  some  explanation.  The  Kalman  filters  are  arranged  in  a 
parallel  fashion  and  operate  concurrently.  Each  filter,  except  the  AINS  filter,  integrates  an 
INS  with  a  different  subset  of  the  aiding  sensors.  As  an  example,  consider  a  configuration 
of  two  INS’s,  one  GPS  receiver  and  one  Loran-C  receiver.  In  this  case  there  are  7  filters,  as 
listed  in  Table  1.  The  first  filter,  which  integrates  the  two  INS’s,  is  used  only  to  assist  in 
INS  failure  isolation  and  not  used  for  navigation.  The  two  unifilters  each  integrate  one  of 
the  INS’s  with  all  of  the  aiding  sensors.  The  4  subfilters  each  integrate  one  of  the  INS’s 
with  all  but  one  of  the  aiding  sensors.  Note  the  filter  “Designation”,  FI-J,  refers  to  the  filter 
based  on  INS  I  using  all  aiding  sensors  but  J.  The  FDIR  algorithm  has  the  responsibility  of 
monitoring  the  health  of  all  the  filters  and  the  individual  sensors  and  of  selecting  the  ‘best’ 
filter  for  output 


Table  1 :  Filters  in  a  Dual  INS,  one  GPS,  one  Loran  configuration 


No.  Filter  Type  Filter  Designation  Sensors 


1 

j r 

AINS 

FO 

INS1,INS2 

2 

Unifilter 

FI 

INSl,  GPS,  Loran 

3 

Unifilter 

F2 

INS2,  GPS,  Loran 

4 

Subfilter 

Fl-2 

INS1,GPS 

5 

Subfilter 

F2-2 

INS2,  GPS 

6 

Subfilter 

Fl-1 

INSl,  Loran 

7 

Subfilter 

F2-1 

INS2,  Loran 

As  stated  previously,  the  primary  role  of  DIINS  is  for  sensor  failure  protection  and  it  uses  its 
traditional  navigation  Kalman  filters  to  obtain  this.  There  are  two  classes  of  failures,  and 
DENS  takes  separate  approaches  to  detect  and  isolate  them.  The  first  class  is  called  hard 
failures.  These  are  the  sudden  and  rapid  failures  of  sensors  that  are  not  uncommon,  for  ex¬ 
ample  when  a  sensor  suddenly  provides  no  data  or  obviously  incorrect  data.  The  second 
class  is  called  soft  failures.  These  are  characterized  by  slowly  degrading  sensor  perform¬ 
ance.  For  example  an  INS  accelerometer  bias  that  slowly  grows  out  of  spec  can  cause 
unreliable  INS  data  if  allowed  to  continue.  In  a  Kalman  filter  integration  system  such  as 
this,  the  filter  will  actually  force  the  effect  of  the  failure  into  inappropriate  filter  error  states. 
In  fact  a  soft  failure  may  be  more  accurately  defined  as  the  result  of  unmodelled  errors 
which  are  large  enough  to  corrupt  the  filtered  results  but  cannot  be  identified  by  hard  failure 
detection  techniques.  Soft  failures  are  almost  exclusively  associated  with  inertial  systems, 
primarily  because  of  their  dependence  on  sensitive  and  finely  tuned  gyroscopes  and  acceler¬ 
ometers  that  are  particularly  affected  by  factors  such  as  temperature  and  gravity  fluctuations. 
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5.2.1.  Hard  Failure  FDIR 

Hard  failure  detection  techniques  rely  on  traditional  Kalman  filter  measurement  residual 
testing  methods.  Residual  tests  can  be  thought  of  as  “reasonableness”  or  “consistency”  tests 
on  the  raw  sensor  data.  These  will  eliminate  the  spurious  data  that  from  time  to  time  show 
up  in  sensor  data.  Any  data  that  does  not  pass  the  residual  test  is  not  used  in  any  of  the 
filters  that  use  that  sensor  and,  in  addition,  a  counter  is  incremented  for  that  sensor.  If.Y%  of 
the  sensor  measurements  over  Y  seconds  fail  the  residual  test,  then  that  sensor  is  considered 
to  have  suffered  a  hard  failure  and  is  removed  from  the  navigation  solution  and  the  operator 
is  notified.  and  Y  are  numbers  chosen  by  the  filter  designer,  but  can  be  adjusted  by  the 
operator  via  the  DIINS  HCI.  If  the  sensor  resumes  healthy  operation  and  passes  the  residual 
test  XX%  of  the  time  over  the  next  YY  seconds,  the  failure  is  considered  to  have  been  fixed 
and  the  sensor  is  considered  healthy  and  can  resume  participation  in  the  navigation  solution. 
There  are  many  subtleties  in  the  actual  implementation  that  cannot  be  described  in  full  detail 
here  but  the  following  overview  describes  the  sequence  of  events  in  the  hard  failure  FDIR 
process. 


S.2.1.1.Hard  Failure  Detection 

First,  measurements  are  not  used  if  the  sensor  involved  passes  a  bad  status  flag  or  other 
indication  that  the  sensor  is  not  operating  properly,  or  if  the  time  stamp  on  the  data  indicates 
it  is  too  old  to  perform  reliable  extrapolation  to  the  current  time.  Next  a  Kalman  filter 
residual  is  computed  and  tested  against  statistically  expected  limits.  The  basic  idea  is  as 
follows:  The  Kalman  filter  measurements  are  actually  differences  between  aiding  sensor 
and  INS  data  (sometimes  called  misclosures).  For  a  particular  parameter  p  (longitude,  for 
example),  the  measurement  Zp  is  computed  as 

Zp=p{Aid)-p(,INS) 

A  Kalman  filter  residual,  v ,  is  defined  as  the  difference  between  the  measurement  and  the 
filter's  predectied  value  of  the  measurement  based  on  all  previous  data: 

V  :=  z—IR 

where  J  is  the  current  Kalman  filter  state  estimate,  and  z  is  the  measurement  vector  which 
is  related  (via  a  linear  matrix  H)  to  the  true  state  vector  x  through  the  measurement  equation 

z  =  Hx  +  ^ , 

where  €  represents  the  measurement  noise.  The  residual  covariance  matrix  is  a  byproduct 
of  the  Kalman  filtering: 


}  =  E{(z  -  )(z  -  mf }  =  HPH'^  +  R 
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where  P  :=  }  is  the  covariance  matrix  of  the  state  estimate  computed  by  the  Kalman 

filter  andi?  :=  ^ }  is  the  covariance  matrix  of  the  sensor  measurement  noise  specified  by 

the  system  designer.  The  test  to  determine  if  a  residual  is  within  statistically  significant 
bounds  is 

[uu^]„  <nP'E{vv^}fi  =m^[HPH^  +^]// 

where  /n  is  an  empirically  selected  integer  typically  in  the  3-5  range,  and  the  ii  subscript 
represents  the  iith  element  of  the  matrix.  In  practice  measurements  are  processed  individu¬ 
ally,  so  the  actual  residual  test  reduces  to  the  scalar  inequality 

Vp\  ^ 

where  CTy  =  (HpPHp  +Rp) .  When  w=3,  this  corresponds  to  approximately  a  99%  confi¬ 
dence  level:  that  is,  99%  of  the  residuals  should  fall  within  ±3a.  In  practice,  /w=5  is  often 
used  to  reduce  the  risk  of  false  alarms  and  to  account  for  the  fact  that  residuals  are  seldom 
truly  statistically  normal,  as  assumed  in  classical  Kalman  filter  derivations. 


5.2.1.2,Hard  Failure  Isolation 

Hard  failure  isolation  (HFI)  requires  that  the  results  from  2  or  more  filters  be  compared. 
This  is  because  any  particular  residual  is  formed  from  the  difference  of  an  INS  and  an  aiding 
sensor  measurement.  Thus  if  a  residual  fails,  it  cannot  be  immediately  determined  whether 
the  INS  or  the  aid  is  to  blame.  For  each  sensor,  a  group  of  hard  failure  isolation  filters  is 
chosen  (the  selection  of  these  filters  is  done  internally  by  DUNS  using  heuristic  algorithms 
created  by  the  system  designers).  A  hard  failure  isolation  is  declared  only  when  all  desig¬ 
nated  HFI  filters  signal  the  failure.  Recovery  fi-om  a  hard  failure  is  declared  as  soon  as  any 
HFI  filter  recovers. 

The  selection  of  which  filters  to  use  for  HFI  relies  on  the  following  general  principles: 

-  The  two  filters  judged  to  be  the  most  effective  for  HFI  for  each  sensor  will  be  used  for 
isolation.  More  than  two  can  increase  the  time  to  isolation. 

-  The  hard  failure  of  any  aiding  sensor  is  best  detected  using  filters  which  use  that  sensor 
as  well  as  the  most  accurate  healthy  sensor 

-  The  hard  failure  of  any  INS  is  best  detected  using  the  AINS  filter  and  the  filter  which 
uses  only  the  failed  INS  and  the  most  accurate  healthy  aiding  sensor.  If  the  AINS  filter 
cannot  be  used  (if  the  other  INS  has  already  failed),  then  select  the  filter  that  uses  only 
the  most  accurate  healthy  aid  and  the  one  that  uses  only  the  second  most  accurate 
healthy  aid. 
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In  addition,  filters  which  have  detected  a  “soft  failure”  (discussed  in  the  next  section)  will 
not  be  used  for  HFI  since  their  state  estimates  are  not  considered  reliable.  As  an  example  of 
hard  failure  isolation,  consider  the  two  INS,  two  aiding  sensor  example  (GPS  and  Loran)  in 
Table  1.  If  we  think  of  the  7  filters  in  a  “tree”  structure  with  the  AINS  filter  at  the  top,  with 
the  left  and  right  sides  of  the  tree  containing  the  filters  associated  with  each  INS,  we  obtain  a 
picture  like  Table  2  below. 

Table  2;  DIINS  Filter  Tree  in  terms  of  Filter  Designation  Numbers 


FO 

FI 

F2 

Fl-1 

Fl-2 

F2-2 

F2-1 

Table  3  illustrates  the  isolation  of  hard  failures  for  each  of  the  INS’s  and  the  two  aiding 
sensors.  In  the  table,  X  indicates  that  filter  is  used  in  the  hard  failure  isolation  procedure  and 
0  indicates  that  filter  is  not  used  to  isolate  a  hard  failure  for  that  sensor.  For  example,  to 
isolate  an  INS2  hard  failure,  use  residuals  from  filters  FO  (the  AINS  filter)  and  F2-2  (the 
INS2+GPS  filter).  To  isolate  a  Loran  failure,  use  Loran  measurement  residuals  from  the 
two  unifilters  FI  (INSl+GPS+Loran)  and  F2  (INS2+GPS+  LORAN). 


Table  3;  Hard  Sensor  Failure  Isolation  Table 


Hard  Failure 

Fl-1 

Fl-2 

FI 

FO 

F2 

F2-2 

F2-1 

INSl 

0 

X 

0 

X 

0 

0 

0 

INS2 

0 

0 

0 

X 

0 

X 

0 

GPS 

0 

0 

X 

0 

X 

0 

0 

Loran 

0 

0 

X 

0 

X 

0 

0 

The  situation  becomes  more  complex  when  more  than  one  failure  occurs.  For  example, 
after  one  of  the  INS’s  has  already  suffered  a  failure,  HH  for  that  INS  is  suspended  and  HFI 
for  the  remaining  sensors  use  the  three  filters  which  do  not  use  the  failed  INS.  If  another 
sensor  fails  after  the  first  INS,  no  subsequent  failure  isolation  is  possible.  (If  the  other  INS 
fails,  there  will  be  no  filter  with  a  healthy  INS,  and  thus  no  filters  available  for  HFI.  If 
either  of  the  remaining  aids  fails  there  will  be  only  one  filter  which  does  not  use  a  failed 
sensor.  This  filter  would  be  used  for  output  and  failure  detection  is  still  possible,  but  there  is 
no  redundancy  left  to  allow  further  isolation.)  The  DIINS  FDIR  algorithm  has  been  pro¬ 
grammed  with  heuristic  logic  such  as  this  for  all  foreseeable  hard  failure  sequences.  It  is  not 
possible  to  describe  all  the  scenarios  here;  full  details  are  described  in  [6] 
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5.2.2.  Soft  Failure  FDIR 


Soft  failures  are  much  more  difficult  to  detect  and  by  definition  cannot  be  detected  by  resid¬ 
ual  tests.  The  definition  states  that  filter  results  will  be  corrupted  by  the  effects  of  a  soft 
sensor  failure,  i.e.,  filter  performance  may  be  worse  than  expected,  but  that  the  effects  of  a 
soft  failure  cannot  be  detected  by  hard  failure  detection  techniques  such  as  residual  tests. 
Various  techniques  have  been  proposed  in  the  literature,  and  the  method  that  was  ultimately 
chosen  for  DIINS  is  based  on  the  (“chi-squared”)  model  similar  to  the  one  described  in 
[9]  and  [10].  In  brief,  the  test  is  based  on  a  comparison  between  two  Kalman  filter  solu¬ 
tions;  one  is  the  usual  filter  with  regular  measurement  updates  from  independent  sensors; 
the  second  solution  uses  the  same  initial  conditions  and  propagation  models  but  does  not 
perform  any  measurement  updates.  A  statistical  test  (based  on  the  distribution)  looks  for 
unexpected  differences  in  the  two  solutions.  A  statistically  significant  difference  triggers  an 
assumption  that  the  filter  has  experienced  a  soft  failure  of  any  one  of  its  component  sensors. 
Again,  the  results  from  multiple  filters  are  used  for  soft  failure  isolation  (SFI).  The  basis  of 
the  x^  test  is  summarized  here. 


5.2.2.1.Soft  Failure  Detection 

The  Kalman  filter  propagation  model  from  time  4-i  to  4  is 


4 


with  a  corresponding  measurement  model 

The  vectors  w  and  v  are  assiimed  to  be  independent,  zero  mean,  Gaussian  white  sequences 
with  covariance  matrices  Q  and  R  respectively.  The  initial  state  vector  xq  is  assumed  to  be  a 
Gaussian  vector  independent  of  iv  and  v  with  covariance  Po-  Both  filters  are  initialized  to 

^(/o)  =  E[x(/o)]  =  4 

P(to)  =  Po 

State  estimates  for  the  filters  are  propagated  according  to 


4(")  = 

Pk(-)  =  V-I + 8k-i 

This  is  the  only  step  used  for  the  no  measurement  filter.  When  a  sensor  measurement  is 
available,  the  other  filter  is  updated  using 
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fli(+)=(/-xt/fi)ii(-). 

This  is  the  step  that  differentiates  the  two  filters.  (Here  (+)  indicates  the  updated  estimate 

•  *2t 

and  (-)  indicates  a  propagated  estimate  just  before  an  update.)  To  describe  the  x  t®st, 
define  the  state  estimates  from  the  two  filters  as  and  Xi ,  for  the  filter  with  and  without 
measurements,  respectively.  The  difference  of  the  two  is  defined  as 

^  A  A 

P-=h-^\ 

Since  both  state  error  vectors  are  assumed  to  be  standard  normal,  fi  \s  standard  normal  as 
well.  Its  covariance  is 

fK  ^  rp  AA*T^  A  A»TT  A  A<TT 

=  E[xiXj  -x\X2  -^2^1  +^2^2! 

=  A“A2“-P21+^2 

Under  conditions  of  optimal  filter  gains,  identical  state  models  and  identical  initial  condi- 
tions,  it  can  be  shown  that  P21  =  P\i  -  P\ 

B^P2-Pi. 

The  x^  test  for  soft  failure  detection  is  performed  on  a  test  statistic  which  is  the  scalar 
quadratic  form  of  : 

The  quadratic  form  of  a  standard  normal  vector  such  as  p  has  a  x  distribution  with  m 
degrees  of  freedom  where  m  is  the  row  dimension  ofyff .  The  probability  thatft^  is  greater 
than  some  value,  Xm .  *s 

ni>^>xl)  =  a 

where  a  is  the  significance  level.  Thus  whenever 
>  Xm,a 
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3.  chi-squared  failure  (i.e.  soft  failure  detection)  will  be  declared.  A  careful  choice  of  oc  is 
required  to  balance  the  risk  of  false  alarms  against  missed  detections.  Typically  values 
between  1  and  5  percent  are  appropriate. 

In  the  DIINS  implementation  of  the  soft  failure  detection  test,  some  heuristic  adjustments 
have  been  made.  First  only  a  portion  of  the  state  vector  is  used  to  compute  .  The  selection 
of  the  subset  to  be  used  was  made  on  the  basis  of  empirical  knowledge,  testing  with  real 
data,  and  the  desire  to  minimize  computational  requirements.  Some  of  these  results  were 
presented  in  [3].  It  was  found  that  using  only  the  INS  system  states  (defined  as  the  position, 

f ,  velocity,  ? ,  and  attitude,  ^ ,  states)  and  not  using  the  other  sensor  error  states 
(gyro/accelerometer  biases,  aiding  sensor  Markov  states,  etc.)  was  the  best  choice.  The 
reasons  for  this  are  given  in  brief;  Using  the  full  state  vector  caused  significant  computa¬ 
tional  burdens  and  also  seemed  to  result  in  many  missed  detections  (the  effect  of  the  soft 
failure  was  ‘diluted’).  Excluding  the  INS  system  states  and  using  only  the  sensor  bias,  etc. 
states  seemed  to  result  in  a  high  false  alarm  rate  (slightly  mismodelled  error  behaviour  may 
be  interpreted  as  a  failure).  Using  all  the  system  states  and  only  the  system  states  produced 
the  best  balance.  This  seems  reasonable  when  one  realizes  that  sensor  error  states  are 
propagated  into  system  states.  Thus  a  sensor  failure  (e.g.  gyro  bias  shift)  which  may  first  be 
reflected  in  the  sensor  error  states  will,  after  some  delay,  be  observable  in  the  system  states 
(attitude  tilt,  position  drift).  This  helps  to  reduce  false  alarms  by  ‘smoothing  out’  transient 
unmodelled  effects.  Similarly  it  was  found  that  only  using  position  error  states,  and  ex- 
eluding  velocity  and  attitude  errors,  produced  more  missed  detections  -  too  much  smoothing 
delays  or  prevents  soft  failure  detection. 


5.2.2.2.Soft  Failure  Isolation 


Soft  failure  isolation  (SFI)  is  similar  to  hard  failure  isolation  in  that  results  from  more  than 
one  filter  are  used,  that  for  each  filter  a  set  of  soft  filter  isolation  filters  is  selected,  that  a  SFI 
is  declared  only  when  all  SFI  filters  signal  the  failure,  and  that  recoveiy  from  a  soft  failure  is 
declared  as  soon  as  any  SFI  filter  recovers.  However,  whereas  the  residual  tests  used  in  hard 
failure  detection  always  identify  two  suspect  sensors,  the  chi-square  test  used  for  soft  failure 
detection  identifies  at  least  two  and  probably  more,  depending  on  the  number  of  aiding 
sensors  in  the  particular  filter.  (Recall  the  soft  failure  detection  algorithm  uses  a  scalar 
statistic  from  a  filter,  so  the  entire  filter  is  tested  as  a  whole.)  The  FDIR  processor  in  DIINS 

is  responsible  for  collecting  the  test  results  from  each  filter,  selecting  the  set  of  SFI  filters 
for  each  sensor  and  determining  when  a  sensor  has  failed  and  when  it  has  recovered. 

As  an  example,  consider  an  INS  that  undergoes  a  soft  failure.  Each  filter  that  uses  that  INS 
will  start  a  timer  when  thez^  test  begins  to  fail.  As  soon  as  the  timer  reaches  a  predefined 
limit  (and  the  chi-square  test  is  still  failing),  each  filter  notifies  the  FDIR  processor.  When 
all  the  failing  INS’s  SFI  filters  have  done  so,  the  FDIR  processor  will  declare  the  INS  soft 
failure.  If  the  failure  is  corrected,  the  failure  isolation  process  is  reversed:  the  tests  start 
passing,  after  predefined  delays  the  filters  notify  the  FDIR  processor,  and  the  INS  is  consid- 
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ered  recovered.  Similar  to  hard  failure  isolation,  SFI  will  not  be  declared  for  a  sensor  which 
is  currently  suffering  a  hard  failure  or  which  is  not  used  in  at  least  two  filters. 

The  selection  of  filters  to  use  for  SFI  for  each  sensor  is  complex  but  follows  these  basic 
principles: 

-  More  than  one  filter  is  required; 

-  SFI  is  more  reliable  when  filters  using  the  minimum  number  of  sensors  (one  INS  and 
one  aid)  are  used; 

-  INS  soft  failures  are  best  detected  with  the  AINS  filter  as  well  as  the  filter  which  uses 
only  the  failed  INS  and  the  most  accurate  healthy  aiding  sensor; 

-  Aiding  sensor  soft  failures  are  best  detected  with  filters  which  use  only  the  failed  sensor 
and  an  INS  (additional  aids  tend  to  dilute  the  test); 

-  When  only  one  INS  is  available,  both  filters  must  be  selected  from  the  good  INS’s 
branch  of  the  filter  tree.  Here  the  choice  is  less  clear,  but  when  possible  the  filter  that 
uses  the  INS  and  all  available  aids  is  selected,  along  with  the  one  that  uses  only  the  INS 
and  the  failing  aid.  The  process  is  less  reliable  in  this  case. 

As  an  example  of  soft  failure  isolation,  consider  the  same  set  of  sensors  and  filters  of  Table 
1.  The  filters  that  are  used  to  declare  a  soft  failme  in  each  of  the  sensors  are  illustrated  in 
Table  4. 


Table  4:  Soft  Sensor  Failure  Isolation  Table 


Soft  Failure 

Fl-1 

Fl-2 

FI 

FO 

F2 

F2-2 

F2-1 

DSfSl 

0 

X 

0 

X 

0 

0 

0 

INS2 

0 

0 

0 

X 

0 

X 

0 

GPS 

0 

X 

0 

0 

0 

X 

0 

Loran 

X 

0 

0 

0 

0 

0 

X 

In  Table  4,  FI  and  FI-J  are  as  defined  in  Table  1,  “X”  indicates  the  filter  failed  the  chi- 
squared  test,  and  “0”  indicates  the  filter  is  not  used  in  the  isolation  process  for  that  sensor. 
Thus  to  isolate  an  INSl  soft  failure,  the  results  from  the  FO  (AINS)  filter  and  the  Fl-2 
(INSl+GPS)  filter  are  used:  both  must  fail  their  chi-square  tests  for  a  sufficient  amount  of 
time  before  the  INS  failure  is  declared. 
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What  happens  after  INSl  has  already  failed?  In  that  case  only  the  filters  containing  INS2 
and  aiding  sensors  are  available  and  the  soft  failure  isolation  process  then  uses  the  results 
from  the  filters  of  Table  5. 


Table  5:  Soft  Failure  Isolation  Table  after  INSl  failure 


Soft  Failure 

Fl-1 

Fl-2 

FI 

FO 

F2 

F2-2 

F2-1 

INSl 

0 

0 

0 

INS2 

0 

X 

X 

GPS 

X 

X 

0 

Loran 

X 

0 

X 

5.3.  Output  Filter  Selection 


To  be  truly  useful,  the  results  of  the  FDIR  process  must  be  used  to  identify  unreliable  filters, 
to  protect  uncorrupted  filters  from  the  effects  of  sensor  failures,  and  to  select  the  ‘best’  filter 
to  be  used  for  navigation.  A  technique  called  filter  classification  is  used  in  DIINS  to  rank 
the  filters  according  to  sensor  and  filter  status  and  use  the  highest  ranking  filter  as  the  source 
of  output  to  drive  the  electronic  chart  display  and  provide  navigation  data.  Selection  of  the 
best  source  for  output  is  based  on  a  combination  of  reliability  and  accuracy.  The  FDIR 
process  is  used  to  judge  filter  and  sensor  reliability  and  a  priori  knowledge  is  used  to  help 
rank  filters  according  to  accuracy.  Individual  filters  in  DIINS  are  not  reconfigured  on  the 
fly  as  sensors  fail  and  recover;  rather  the  filters/sensors  are  flagged  as  failed  and  a  filter 
selection  algorithm  chooses  from  the  currently  healthy  filters. 

A  filter  is  considered  for  output  only  if  it  is  not  the  AINS  filter,  has  a  good  INS,  and  has  not 
failed  the  chi-squared  test.  Of  those  filters  that  are  judged  to  be  candidates  for  filter  output, 
the  FDIR  processor  selects  the  one  that  has  the  lowest  estimated  radial  position  error  stan¬ 
dard  deviation  (from  the  Kalman  filter  covariance  estimates).  If  more  than  one  filter  have 
similar  accuracy  estimates,  then  the  one  which  has  the  largest  number  of  healthy  aiding 
sensors  is  selected.  In  the  case  when  both  INS’s  have  failed  and  there  are  no  Kalman  filters 
considered  reliable,  DIINS  outputs  the  navigation  data  from  the  most  accurate  healthy  aiding 
sensor.  In  the  truly  worst  case  when  there  are  no  sensors  that  are  considered  healthy,  DIINS 
continues  to  search  for  the  “least  unhealthy”  sensor  (e.g.,  one  that  is  still  supplying  data  even 
though  it  may  currently  be  flagged  as  suffering  a  soft  failure).  Of  course  the  operator  is 
notified  of  all  such  circumstances. 
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6.  REPRESENTATIVE  DIINS  SEA  TRIAL  RESULTS 

DENS  has  been  demonstrated  on  many  sea  trials.  These  ranged  from  simple  data  collection 
trials  on  research  ships  for  later  post-processing,  to  ftdl  real-time  implementations  on  a  Navy 
frigate  in  operational  trials.  For  the  designers,  the  best  experiments  are  controlled  trials  on  a 
dedicated  research  vessel,  during  which  complete  control  over  the  trial  can  be  maintained. 

In  addition,  post-processed  DGPS  reference  system  data  set  was  used  to  generate  the  'true' 
trajectory  against  which  the  DENS  performance  could  be  evaluated.  One  such  trial  is  de¬ 
tailed  in  [7].  While  it  is  not  possible  to  present  all  of  the  detail  of  these  trials  in  this 
overview,  a  few  representative  results  are  shown. 

The  following  data  was  collected  during  a  real  time  trial  of  DENS  on  a  research  vessel  off 
the  Canadian  west  coast  in  1995.  The  sensor  suite  for  that  trial  consisted  of  dual  Sperry 
MK-29  inertial  navigators,  a  Trimble  TANS  P/Y  GPS  receiver  and  an  Intemav  LC360  Lo- 
ran-C  receiver.  A  post  processed  differential  GPS  system  was  used  as  the  reference. 

The  system  generally  performed  extremely  well.  When  PAT  GPS  was  available,  position 
accuracy  on  the  order  of  5  m  RMS  or  less  was  obtained  (Figure  7  shows  the  position  OTor 
from  the  INSl/GPS/Loran  unifilter).  What  is  more  interesting  is  to  observe  the  behaviour  of 
DENS  during  sensor  failures.  Figure  8  shows  a  situation  when  the  GPS  receiver  fails  at  1.4 
hours  into  the  plotted  segment  of  the  run.  Prior  to  that  time,  the  DENS  integrated  position 
error  is  in  the  5-6  m  range  (the  previous  figure)  even  though  the  raw  unaided  INS  position 
errors  are  several  kilometers.  When  the  GPS  fails  suddenly,  DENS  immediately  suspends 
GPS  measurements  to  all  filters  that  use  it.  As  can  be  seen,  the  position  errors  and  the  posi¬ 
tion  error  estimated  standard  deviation  eventually  grow  to  about  500  m,  roughly  the 
expected  accuracy  of  the  Loran  system  at  the  location  of  the  trials. 

An  example  of  soft  failure  detection  is  shown  in  the  subsequent  figures.  Figure  9  shows  the 
raw  position  errors  of  the  two  INS’s.  It  was  later  determined  that  INS2  had  suffered  a  soft 
gyro  failure  beginning  at  about  1 .5  hours  into  the  run.  The  fault  could  not  be  picked  up  with 
the  standard  residual  test,  as  shown  in  Figure  10.  The  effects  of  the  gyro  failure  were  gradu¬ 
ally  being  distributed  among  all  3  gyro  bias  state  estimates.  Figure  11,  (and  others  as  well) 
in  all  the  Kalman  filters  that  used  INS2.  However  the  chi-square  test  statistic  from  the  INSl 
and  INS2  unifilters  plotted  in  Figure  12  clearly  indicate  that  there  is  a  problem  in  the  state 
estimates  of  the  filters  using  INS2.  The  chi-square  test  eventually  fails  about  2.5  hours  into 
the  runs  and  the  SFI  logic  isolates  the  problem  to  INS2.  The  operator  is  notified  and  INSl 
becomes  the  primary  INS  at  that  point,  if  it  had  not  already  been  so. 
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Figure  7:  Typical  DUNS  unifilter  radial  position  errors  and  1-sigma  estimates,  no  failures 


Figure  8:  Graceful  degradation  of  DIINS  position  errors  after  GPS  hard  fail  at  1.4  hrs. 
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Figure  9:  INS  Radial  position  errors,  INS  soft  fail  at  1.5  hrs. 
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Figure  10:  GPS  north  and  east  position  residuals  (and  S-sigma  limit)  from  INS2  unifilter  af¬ 
ter  soft  fail 
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Figure  12:  Normalized  Chi-squared  results  from  unifilters 
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7.  DUNS  SIMULATION  SYSTEM 

A  DIINS  simulation  system  was  also  created  during  the  project’s  development.  It  was 
designed  to  be  as  flexible  as  possible  in  order  to  be  suitable  for  other  integrated  navigation 
system  simulations.  It  has  been  designed  to  exercise  all  of  the  DIINS  failure  modes  which 
cannot  be  easily  stimulated  in  a  real  sensor  environment.  It  consists  of  a  separate  set  of 
software  programs  to  generate  simulated  trajectory  data  and  high  fidelity  sensor  simulators 
to  replicate  sensor  performance  under  that  trajectory  and  user  controlled  anomalies.  The 
models  are  generally  of  higher  order  than  the  models  used  in  the  DIINS  Kalman  filters.  For 
example,  the  INS  simulator  models  many  classical  inertial  errors  such  as  sensor  scale  factor 
nonlinearities,  g-sensitive  drifts,  misalignments,  random  walk  and  digitization  effects 
whereas  the  DUNS  Kalman  filters  effectively  lump  all  these  in  an  exponentially  correlated  ^ 
bias  state  for  each  sensor  with  an  appropriate  value  in  the  system  process  noise  matrix  (“Q” 
matrix).  The  simulated  sensor  data  can  be  used  in  DIINS  for  experimentation  and  analysis. 
Similarly  recorded  sensor  data  can  be  post  processed  by  DUNS.  This  facility  has  proven 
invaluable  during  the  development  phase.  The  facility  can  also  be  used  to  playback  re¬ 
corded  sea  trial  sensor  data  in  real-time  to  support  end-to-end  laboratory  testing  and  post 
mission  analysis  of  an  operational  DUNS. 

8.  Dims  AND  THE  CANADIAN  NAVY 

DIINS-capable  SHINNADS  units  are  being  installed  in  the  fleet  in  1999  and  2000.  DUNS  is 
to  undergo  final  trials  in  late  1999  and  plans  are  being  made  to  retrofit  the  SHINNADS  units 
with  the  DUNS  processors  in  2000  or  2001.  Plans  are  also  being  developed  to  study  the 
feasibility  of  replacing  the  relatively  simple  navigation  computations  that  presently  occur 
within  the  ship's  Command  and  Control  computer  system  (CCS)  with  DUNS.  This  would 
involve  software  changes  in  the  CCS  to  enable  it  to  accept  DUNS  formatted  data,  and  for  it 
to  allow  DUNS  to  be  "Nav  Central"  for  the  ship.  An  analysis  of  the  various  configuration 
options,  operational  impacts  and  installation  costs  is  presently  being  conducted. 

9.  SUMMARY 

This  report  has  presented  a  summary  of  the  Canadian  Navy's  Dual  Inertial  Integrated  Navi¬ 
gation  System,  as  developed  by  the  Defence  Research  Establishment  Ottawa  for  the  Navy's 
patrol  fi'igates.  The  underlying  philosophy  and  design  goals  have  been  presented  along  with 
the  architecture  chosen  to  achieve  them.  Some  of  the  details  and  results  of  the  multi-filter 
implementation  of  that  architecture  have  been  presented  along  with  some  results  from  a 
number  of  controlled  sea  trials  which  demonstrate  the  accuracy  and  sensitivity  of  the  sys¬ 
tem.  The  integration  of  the  DUNS  navigation  computer  with  an  ECDIS  electronic  chart 
system  has  demonstrated  the  ease  of  use  of  such  a  sophisticated  integrated  navigation  system 
aboard  a  major  vessel.  The  future  plans  for  DUNS  have  been  outlined. 
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APPENDIX  A:  DESCRIPTION  OF  DIINS  OUTPUT  DATA  STREAM 


1 .  Introduction:  An  RS232  port  (default  port  3)  on  the  DUNS  ADM  will  be  used  to 

provide  serial  data  to  user  systems.  This  document  describes  the  output  of  the  DUNS 
ADM,  software  version  3s2. 


2,  Physical:  The  pin-outs  on  the  RS-232  DB9  Male  Connector  are  standard: 


1. 

DCD 

6. 

DSR 

2. 

RXD 

7. 

RTS 

3. 

TXD 

8. 

CTS 

4. 

DTR 

9. 

NC 

5. 

GND 

3.  Communication  Parameters:- 19,200  baud, 

-  8  data  bits,  no  parity,  1  stop  (8N1) 

-  software  handshake  (xon,xoff). 

4.  ASCII  Outnut  Sentences:  The  DUNS  ADM  data  output  will  be  contained  in  ten 
data  sentences  as  follows: 


a)  DUNS  position  ($INGLL):  -  Latitude 

-  Longitude 
-time 

-  status 

-  checksum 


b)  DENS  heading  (SINHDT):  -heading 

-  checksum 


c)  DENS  velocity,  error  estimate 

and  FDIR  status  ($PDR01):  -  track  angle  COG 

-  ground  speed  SOG 

-  north  position  standard  deviation  estimate 

-  east  position  standard  deviation  estimate 

-  95  percentile  radial  error  estimate 

-  FDIR  Status 

-  checksum 

d)  DENS  attitude  ($PDR02):  -  heading 

-  pitch 
-roll 

-  checksum 
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e)  GPS  (GPSi ,  GPS2)  position  ($GPGGA): 


-  time 

-  Latitude 

-  Longitude 

-  quality 
-HDOP 

-  checksum 

Note;  GPSi  is  Trimble  P(Y),  GPS2  is  DGPS 

f)  GPS  (GPS  1 ,  GPS2)  velocity  (SGPVTG):  -  track  angle  COG 

-  groimd  speed  SOG 

-  checksum 

g)  INS  (Mk29i,  Mk292)  position  ($HEGLL):  -  Latitude 

-  Longitude 
-time 

-  status 

-  checksum 

h)  INS  (Mk29i,  Mk292)  heading  ($HEHDT):  -  heading 

-  checksum 

i)  INS  (Mk29i,  Mk292)  velocity  (SHEVTG):  -  track  angle  COG 

-  ground  speed  SOG 

-  checksum 

j)  Loran-C  (LC360)  position  ($LCGLL):  -  Latitude 

-  Longitude 

-  time 

-  status 

-  checksum 

5,  Data  Sen***"****  The  encapsulation  of  these  data  sets  will  conform  to  NMEA 

0183  (version  2.00)  where  possible. 

a)  DTTNS  position  data  is  contained  in  the  pre-defmed  NMEA  0183  (version  2.00)  sen¬ 
tence  GLL.  The  Talker  Identifier  Mnemonic  in  this  case  will  be  IN,  for  Integrated 
Navigation. 

$INGLL,lllLll,a,yyyyy.yy,a,hhmmss.ss,A*hh<CR><LF> 

1111.11, a  WGS84  Latitude  ddmm.mm,N/S 

yyyyy.yy,a  WGS84  Longitude  dddmm.mm,EAV 

hhmmss.ss  DENS  Time  of  Position 

A  Status  (A=Valid,  V=Not  valid) 
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hh 


checksum 


Example:  $INGLL,4520.821,N, 07553.328, W,150759.13,A*0E 

b)  PENS  heading  data  is  contained  in  the  NMEA  0183  (version  2.00)  sentence  HDT : 
$INHDT^.x,T*hh<CR><LF> 

x.x,T  Heading  (0-360  degrees  True  from  North,  W GS84) 

hh  checksum 

Example:  $INHDT,248.568,T*20 

c)  PENS  Velocity.  Error  estimate  and  Status:  Unfortunately  the  predefined  NMEA 
sentence  structures  do  not  include  covariance  information  (which  is  an  important  output 
of  integrated  navigation  systems),  and  do  not  provide  true  velocity  in  a  reasonable  for¬ 
mat.  Therefore  a  custom  sentence  structure  is  defined  to  contain  these  items: 

$PDR01,x.x,T^xMfX^>N,xjc,E,x.x,C,c-c*hh<CR><LF> 

where  the  manufacturer's  Mnemonic  code  is  PRO  for  Pefence  Research  Ottawa,  the  1 
distinguishes  this  from  other  proprietary  sentence. 

x.x,T  Track  angle  COG  (0-360  degrees  True  from  North,  WGS84) 

x.x,M  Speed  over  groxmd  SOG  (m/s) 

x.x,N  North  error  estimate,  standard  deviation  (meters) 

x.x,E  East  error  estimate,  standard  deviation  (meters) 

x.x,C  95%  radial  position  error  estimate  (meters) 

c— c  PENS  FPIR  status  word  (character  field) 

hh  checksum 

The  PENS  FDIR  status  word  (c — c)  is  a  7  character  field  that  can  be  used  to  determine 
the  overall  health  of  PENS,  the  current  status  of  the  individual  sensors,  md  which 
PENS  internal  filter  is  presently  being  used.  The  meaning  of  each  digit  is  described 
here:  From  left  to  right:  (Character  1  ->  1111012  <-  Character  7) 

Character 

1  INSl  Status 

1=  Used  in  current  filter  and  FPI  status  is  good 
0=  Not  used  in  current  filter  or  FPI  status  is  bad 

2  INS2  Status 

1=  Used  in  current  filter  and  FPI  status  is  good 
0=  Not  used  in  current  filter  or  FPI  status  is  bad 

3  GPSl  Status 

1=  Used  in  current  filter  and  FPI  status  is  good 
0=  Not  used  in  current  filter  or  FPI  status  is  bad 

4  GPS2  Status 

1=  Used  in  current  filter  and  FPI  status  is  good 
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0=  Not  used  in  current  filter  or  FDI  status  is  bad 

5  Loran  Status 

1=  Used  in  current  filter  and  FDI  status  is  good 
0=  Not  used  in  current  filter  or  FDI  status  is  bad 

6  DIINS  Overall  Health 

l=At  least  one  valid  integrating  filter, 

0=No  valid  INS  or  Kalman  filter.  Best  Single  sensor  is  being  output 

7  Which  internal  Filter  is  currently  selected  for  output 

1  through  F  (hex) 


Example:  $PDR01, 41 .466,1, 0.009,M,3.1,N, 3.1, E,7.6,C,01 1 1 1 13*60 

d)  DUNS  Attitude:  The  predefined  NMEA  sentence  structures  do  not  include  attitude 
information.  Therefore  a  second  proprietary  sentence  structure  is  defined: 

$PDR02^,x.x^*hh<CR><LF> 

where  from  left  to  right, 

X.X,  Heading  (deg),  deg  from  North  True  (0-360) 

X.X,  Pitch  (deg).  Bow  down  positive  (USN  convention.  DIINS  internal  convention 
is  bow  up  positive) 

X.X  Roll  (deg).  Starboard  up  positive  (USN  convention.  DIINS  internal  conven¬ 
tion  is  starboard  down  positive) 

Example:  $PDRO2,248.563,-0.662,0.387*  14 


e)  GPS  Position:  For  the  GPS  data  the  GGA  sentence  will  be  used  (possibly  with  null 
fields). 

$GPGGA,hhmmss.ss,UlUl,a,yyyyy.yy,a,q,nn,d.d,x^^,x^x,M^x,xxxx*hh<CR><LF> 


hhmmss.ss  UTC  Time  of  Position 
llll.ll,a  WGS84  Latitude  ddmm.mm,N/S 

yyyyy,yy^a  AVGS84  Lougitude  dddnim.mm,EAV 

q,  GPS  Quality 

0  =  Fix  not  available  or  not  valid  (From  sensor  DCT) 

1  =  GPS  fix  valid 

2  =  DGPS  SPS  mode,  fix  valid  [May  not  be  present] 

3  =  GPS  PPS  mode,  fix  valid  [May  not  be  present] 

nn,  number  of  satellites  in  view  [May  be  null] 

d.d  HDOP 

(Rest  of  fields  may  be  null) 
hh  checksum 


Example:  $GPGGA,150801.01,4520.821,N,07553.326,W,1,,1.0,„„,  48 
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f)  GPS  Velocity:  For  the  GPS  velocity  data  the  VTG  sentence  will  be  used: 

$GPVTG,x.x,T,x.x,M^N,x.x,K*hh<CR><LF> 

x.x,T  Track  angle  COG  (0-360  degrees  True  from  North,  WGS84) 

x.x*M  Track  angle  COG  (degrees  Magnetic)  [May  be  Null] 

x.x,N  Speed  over  ground  (knots) 

x.x,K  Speed  over  ground  (km/hr) 

hh  checksum 

Example:  $GPVTG,263.000,T„M,0.053996,N,0.100000,K*66 


NOTE  1:  To  identify  which  GPS  the  $GPGGA  and  SGPVTG  data  conies  from  (i.e. 
GPSl  or  GPS2),  each  pair  of  these  messages  will  always  be  preceded  with  the  appropri¬ 
ate  STN  sentence: 

$GPSTN,xx*hh<CR><LF> 

where  xx  is  either  01  or  02. 

NOTE  2;  The  $GPSTN,  $GPGGA,  SGPVTG  sentences  will  always  appear  as  a  set 
corresponding  to  one  or  the  other  of  the  GPS’s.  That  is,  there  will  be  a  set  of  sentences 
in  the  order  ($GPSTN,01 ...  SGPGGA  ....  GPVTG)  corresponding  to  GPSl  and  another 
set  ($GPSTN,02  ...  SGPGGA ....  SGPVTG)  corresponding  to  GPS2.  These  sets  of  sen¬ 
tences  will  not  be  intermixed  with  each  other,  although  other  sentences  (particularly  the 
high  rate  SPDR02)  may  be  intermixed  with  them. 


gi  INS  Position:  The  Inertial  position  data  will  be  contained  in  the  approved  GLL  sen¬ 
tence  format.  There  is  no  INS  "Talker  Mnemonic",  however  HE  comes  close. 

llll.ll,a  Latitude  ddmm.mm,N/S 

yyyyy.yy,a  Longitude  dddmm.mm,E/W 
hhmmss.ss  DIINS  Time  of  Position 

A  Status  (A= Valid,  V=Not  valid)  from  sensor  DCT 

hh  checksum 

Example:  SHEGLL,4520.916,N,07553.050,W,154247.19,A  09 


h)  tmq  HftaHingr  The  Inertial  heading  data  will  be  contained  in  the  HDT  sentence  for¬ 
mat. 
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SHEHDTyXJC,  T*hh<CR><LF> 

x.x,T  Heading  (0-360  degrees  True  from  North) 

hh  checksum 

Example:  $HEHDT, 248.566,1*24 

i)  TNS  Velocity:  The  Inertial  course  and  speed  data  will  be  contained  in  the  approved 
VTG  sentence  format. 

$HEVTG,x^J,xjc,M^N^xJK*hh<CR><LF> 

Track  angle  or  CMG  (0-360  degrees  True  from  North, 

Track  angle  or  CMG  (degrees  Magnetic)  [May  be  Null] 
Speed  (knots) 

Speed  (km/hr) 
checksum 


x.x,T 

WGS84) 

x.x,M 

x.x,N 

x.x,K 

hh 


Example:  $HEVTG,95. 194,T„M,0.043 146,N,0.079906,K*4F 


NOTE  1:  To  identify  which  INS  the  SHEGLL,  $HEHDT  and  SHEVTG  data  comes 
from  (i.e.  INSl  or  INS2),  each  set  of  these  messages  will  always  be  preceded  with  the 
appropriate  STN  sentence: 

$HESTN,xx*hh<CR><LF> 

where  xx  is  eifrier  01  or  02. 


NOTE  2;  The  SHESTN,  SHEGLL,  SHEHDT,  SHEVTG  sentences  will  always  appear 
as  a  set  corresponding  to  one  or  the  other  of  the  INS’s.  That  is,  there  will  be  a  set  of 
sentences  in  the  order  ($HESTN,01 ...  SHEGLL  ....  SHEHDT. .  .SHEVTG)  correspond¬ 
ing  to  INSl  another  set  (SHESTN,02  ...  SHEGLL ....  SHEHDT... SHEVTG) 
corresponding  to  INS2.  These  sets  of  sentences  will  not  be  intermixed  with  each  other, 
altVimigh  other  sentences  (particularly  the  high  rate  SPDR02)  may  be  intermixed  with 
them. 


j)  Trtran-C  position  data  will  be  contained  in  the  approved  GLL  sentence  format: 
$LCGLL,lllUl,a,yyyyy.yy,a,hhmmss.ss,A*hh<CR><LF> 


1111.11, a 
yyyyy-yy.a 

hhmmss.ss 

A 

hh 


WGS84  Latitude  ddmm.mm,N/S 
WGS84  Longitude  dddmm.mm,EAV 
DIINS  Time  of  Position 

Status  (A=Valid,  V=Not  valid)  from  Sensor  DCT 
checksum 
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Example:  $LCGLL,4520.467,N,07552.967,W,1 54257.49, A*08 
6.  Output  Rates: 

INS  sentences  ($HEGLL(5.g),  $HEHDT(5.h)  and  $HEVTG(5.i))  are  output  every  1.28 
seconds 

DIINS  sentences  ($INGLL(5.a),  $INHDT(5.b),  $PDR01(5.c))  are  output  at  an  integer  mul¬ 
tiple  of  1.28  seconds  (ranging  from  1  to  7  depending  on  the  configuration). 

Attitude  data  sentence  ($PDR02(5.d))  is  output  every  80  milliseconds. 

GPS  ($GPGGA(5.e),  $GPVTG(5.f))  and  Loran  ($LCGLL(5.j))  sentences  will  be  output  as 
available  (approximately  every  second). 


7.  Sample  Output:  The  following  is  a  sample  of  DIINS  output : 

$HESTN,01*69 

$HEGLL,4522.589,N,0755 1 .267,W,1 54254.47,  A*0C 
$HEHDT,246.857,T*25 

$HEVTG,53.448,T„M, 0.846107, N, 1.566990, K*4C 
$PDRO2,248.559,-0.657,0.38 1  •  ID 
$PDRO2,248.565,-0.662,0.384*l  1 
$PDR02,248.559, -0.657,0.384*  1 8 
$PDR02,248.565,-0.659,0.381*1C 
$PDRO2,248.559,-0.654,0.384*lB 
$HESTN,02*6A 

$HEGLL,4520.916,N,07553.050,W,154245.91,A*OB 

$HEHDT,248.566,T*24 

$HEVTG,1 01 .3 1 0,T„M,0.039836,N,0.073776,K*7D 

$PDRO2,248.559,-0.657,0.384*18 

$PDRO2,248.565,-0.657,0.376*lA 

$PDRO2,248.559,-0.657,0.381  *  1 D 

$PDRO2,248.565,-0.662,0.381*14 

$PDRO2,248.559,-0.662,0.384*lE 

$PDRO2,248.565,-0.654,0.384*14 

$HESTN,01*69 

$HEGLL,4522.589,N,0755 1 .267,W,1 54255.75,A*0C 
$HEHDT,246.863,T*22 

$HEVTG,53.393,T„M,0.851571,N,1.577110,K*4E 

$PDRO2,248.559,-0.659,0.384*16 

$GPSTN,02*70 

$GPGGA,154256.26,4520.822,N,07553.328,W,2„2.4,,,,,,*48 

$GPVTG,0.000,T„M,0.021598,N,0.040000,K*63 

$PDRO2,248.559,-0.657,0.384*  1 8 

$LCGLL,4520.467,N,07552.967,W,154256.51,A*00 

$PDRO2,248.559,-0.654,0.381*lE 

$PDRO2,248.565,-0.657,0.384*17 

$PDRO2,248.559,-0.657,0.384*18 

$PDRO2,248.565,-0.657,0.384*17 

$PDR02,248.565 ,-0.657,0.38 1*12 

$PDRO2,248.565,-0.657,0.384*17 

$PDRO2,248.559,-0.657,0.384*18 

$PDRO2,248.559,-0.654,0.381*lE 

$HESTN,02*6A 

$HEGLL,4520.916,N,07553.050,W,154247.19,A*09 

$HEHDT,248.566,T*24 

$HEVTG,95.194,T„M,0.043146,N,0.079906,K*4F 
$PDR02,248.559, -0.657,0.38 1  *1 D 
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$PDR02^48.565,-0.659.0.384*  1 9 
$PDR02,248.565,-0.657,0.384‘  1 7 
$PDRO2,248.559,-0.662,0.38I  •  1 B 
$PDR02,248.559,-0.654,0.381  •  1 E 
$PDR02, 248.559,-0.657, 0.381  *1D 
$PDRO2,248.559,-0.662,0.38 1  •  1 B 
$PDR02,248.559, -0.654,0.384*  1 B 
$GPSTN,01*73 

$GPGGA,154257.00,4520.822,N,07553.330,W,1„1.0„„„*40 
$GPVTG,263.000,T„M,0.053996,N,0. 1 00000,K*66 
jHESTN  01*69 

$HEGLM522.589,N,0755 1 .267,  W,  1 54257.03w^*0F 
$HEHDT,246.863,T*22 

$HEVTG,53.604,T„M,0.849248,N,1.572807,K*4B 

$PDRO2,248.565,-0.657,0.376*lA 

$GPSTN,02*70 

$GPGGA,154257.26,4520.822,N,07553.328,W,2„2.4„„„*49 

$GPVTG,0.000,T„M,0.026998,N,0.050000,K*69 

$LCGLL,4520.467,N,07552.967,W,154257.49,A*08 

$INGLL,4520.823,N,07553.328,W,154247.19,A*08 

$INHDT,248.559,T*22 

$PDR01,35.253,T,0.040,M,2.6,N,2.6,E,6.4,C,01 1 1 1 13*6D 

$PDR02,248.565, -0.662,0.381  *14 

$PDR02,248.559, -0.654,0.381  *1E 

$PDRO2,248.565,-0.657,0.384*  1 7 

$PDRO2,248.565,-0.654,0.384*14 

$PDR02,248.559, -0.654,0.381  *1E 

$PDR02,248.559, -0.657,0.384*  1 8 

$PDR02,248.565, -0.654,0.381*1 1 

$HESTN,02*6A 

$HEGLL,4520.916,N,07553.050,W,154248.47,A*0D 

$HEHDT,248.571,T*22 

$HEVTG,100.305,T„M,0.043673,N,0.080883,K*73 
$PDRO2,248.565,-0.657,0.384*  1 7 
$PDRO2,248.565,-0.657,0.384*  1 7 
$PDRO2,248.565,-0.657,0.384*  1 7 
$PDRO2,248.559,-0.654,0.381  *  1 E 
$PDRO2,248.565,-0.657,0.384*  1 7 
$PDRO2,248.559,-0.662,0.381  *  1 B 
$PDRO2,248.559,-0.654,0.384*  1 B 
$PDRO2,248.559,-0.659,0.384*  1 6 
$GPSTN,01*73 

$GPGGA,154258.00,4520.822,N,07553.330,W,1„1.0„„„*4F 

$GPVTG,318.000,T„M,0.053996,N,0.100000,K*6B 

$PDRO2,248.565,-0.657,0.381*12 

$GPSTN,02*70 

$GPGGA,154258.26,4520.822,N,07553.328,W,2„2.4„„„*46 

$GPVTG,0.000,T„M,0.021598,N,0.040000,K*63 

$PDRO2,248.565,-0.657,0.376*  1 A 

$PDRO2,248.559,-0.657,0.38 1  *  1 D 

$PDRO2,248.565,-0.654,0.379*16 

$HESTN,01*69 

$HEGLL,4522.589,N,07551.266,W,154258.31,A*00 

$HEHDT,246.868,T*29 

$HEVTG,53.393,T„M,0.851571,N,1.577110,K*4E 
$PDR02,248.559,-0.654,0.379*19 
$PDR02,248.559,-0.657,0.384*  1 8 
$PDRO2,248.565,-0.657,0.384*  1 7 
$PDRO2,248.559,-0.659,0.387*  1 5 


APPENDIX  B:  SHINNADS  DISPLAY  of  DIINS  DATA 


This  table  is  used  to  deteraiine  which  fields  (indicated  as  underlined)  of  the  DIINS  data  sen¬ 
tences  are  used  to  drive  the  corresponding  area  on  the  SHINNADS  display  screen.  The  column 
on  the  right  indicates  the  units  in  which  the  data  is  transmitted  (and  not  necessarily  what  is 
displayed  on  the  SHINNADS  screen). 

SHINNADS 


DISPLAY  AREA 

Info  obtained  from 

Units 

DIINS  SOLUTION: 

Latitude 

$INGLL.llll.lLa,vvvvv.vv,a,hhmmss.ss,A 

ddmm.mmm 

Longitude 

STNGLL.llll.lLa.vvvvv.vv.a.hhmmss.ss,A 

dddmm.mmm 

heading 

$INHDT^,T 

deg 

COG 

$PDRO  1 ,2yc,T,x.x,M,x.x,N,x.x,E,x.x,C,ccccccc 

deg 

SOG 

$PDRO  1  .x.x.T.x.x.M.x.x.N.x.x.E.x.x,C,ccccccc 

m/s 

Est.Error  (95%) 

$PDR01,x.x,T,x.x,M,x.x,N,x.x,E,2yc,C,ccccccc 

meters 

North  st.dev. 

$PDRO  1  ,x.x,T,x.x,M,2LX,N,x.x,E,x.x,C,ccccccc 

meters 

East  St.  dev. 

SPDRO 1  ,x.x,T,x.x,M^.x,N,2yc,E,x.x,C,ccccccc 

meters 

DIINS  STATUS: 

Status 

$PDR01,x.x,T,x.x,M,x.x,N,x.x,E,x.x,C,ccccccc 

Oor  1 

NOTE:  The  overall  DENS  status  is  displayed  as  "Good"  if  this  character  equals  1,  and  "Single 
Sensor"  if  it  equals  0. 

Currently  Integrating 

INSl  ? 

$PDR01,x.x,T,x.x,M,x.x,N,x.x,E,x.x,C,ccccccc 

uor  1 

INS2? 

$PDR01,x.x,T,x.x,M,x.x,N,x.x,E,x.x,C,ccccccc 

0  or  1 

GPSl? 

$PDR01,x.x,T,x.x,M,x.x,N,x.x,E.x.x,C,ccccccc 

Oor  1 

GPS2? 

$PDR01,x.x,T,x.x,M,x.x,N,x.x,E,x.x,C,ccccccc 

Oor  1 

Loran  ? 

SPDRO  1  ,x.x,T,x.x,M,x.x,N,x.x,E5X.x,C,ccccccc 

Oor  1 

NOTE:  The  sensors  listed  in  the  "Currently  Integrating"  box  are  the  ones  that  have  the  above 
underlined  corresponding  "used"  character  above  equal  to  1 

Raw  Data 

GPSl  (TANS  P(Y)): 

$GPSTN,01  then 


Latitude 

Longitude 

Heading 

SOG 


$GPGGA,hhmmss.ss,lllLlLa,yyyyy.yy,a,q,nn,d.d,x.x,„,„  ddnun.mmm 
$GPGGA,hhnmiss.ss4111.11,a,yyyyyjy^,q,nn,d.d,x.x,„„,  dddmm.mmm 

N/A 

$GPVTG,x.x,T,x.x,M,x.x.N,2yc,K  km/hr 
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COG 

$GPVTG,2yc,T,x.x,M,x.x.N,x.x,K 

deg 

Status 

$PDRO  1  ,x.x,T,x.x,M,x.x,N,x.x,E,x.x,C,ccccccc 

l=Used 

0=lgnored 

GPS2  (DGPS): 

$GPSTN,02  then 

Latitude 

$GPGGA.hhmmss.ss.llll.ll.a.vvwv.w.a,a.nn,d.d„„„ 

ddmm.mmm 

Longitude 

SGPGGA.hhmniss.ssdlll.ll.a.vvvw.w.a.a,nn.d.d . 

dddnun.nunm 

Heading 

N/A 

— 

SOG 

SGPVTGtX.x.T.x.x.M.x.x.N.x.x.K 

km/hr 

COG 

$GPVTG.x.x.T.x.x.M.x.x.N.x.x,K 

deg 

Status 

$PDRO  1  ,x.x,T,x.x,M,x.x,N,x.x,E,x.x,C,ccccccc 

l=Used 

0=lgnored 

INSl  (Mk29  FORE): 

$HESTN,01  then 

Latitude 

$HEGLL.llll.lLa.vvvw.w.a.hhnimss.ss,A 

ddmm.mmm 

Longitude 

SHEGLL.llll.ll.a.vvvw.w.a.hhnimss.ss,A 

dddmm.mmm 

Heading 

$HEHDT.x.x.T 

deg 

SOG 

SHEVTG.X.X.T.X.X.M.X.X.N.X.X.K 

km/hr 

COG 

$HEVTG,x.x,T,x.x,M,x.x.N,x.x,K 

deg 

Status 

$PDRO  1  ,x.x,T,x.x,M,x.x,N,x.x,E,x.x,C,ccccccc 

l=Used 

0=lgnored 

INSl  (Mk29  AFT): 

$HESTN,02  then 

Latitude 

$HEGLL.llll.ll.a.vvvw.w,a,hhnunss.ss,A 

ddmm.nunm 

Longitude 

SHEGLL.llll.lLa.vvvw.w,a,hhmniss.ss,A 

dddmm.mmm 

Heading 

$HEHDT.x.x.T 

deg 

SOG 

$HEVTG,x.x,T,x.x,M,x.x.N,2LX,K 

km/hr 

COG 

!RHEVTG.x.x.T.x.x.M,x.x.N,x.x,K 

deg 

Status 

$PDRO  1  ,x.x,T,x.x,M,x.x,N,x.x,E,x.x,C,ccccccc 

l=Used 

0=lgnored 

LORAN-C  (LC360): 

Latitude 

$LCGLL.llll.lLa.vvvw.w,a,hhnunss.ss,A 

ddmm.mmm 

Longitude 

SLCGLL.llll.ll.a.vvwv.w,a,hhmmss.ss,A 

dddmm.mmm 

Heading 

N/A 

SOG 

N/A 

““ 

COG 

N/A 
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Status 

TIME: 


$PDR01,x.x,T,x.x,M,x.x,N,x.x,E,x.x,C,ccccccc 
$TMrH  T  .1111  11  ,a  ,yyyyy  w.a.hhmmss.SS.A 


l=Used 

O=lgnored 
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